Thank you!

Thanks Fedor. Not sure why nobody mentioned this to us on the bitcoin-dev mailing list when I asked for suggestions on how to construct the commitment, but oh well.

We also might want to start requiring the commitment on every block after activation. Mining ext. blocks would still be opt-in, but now all miners would need to upgrade. Shouldn't be an issue assuming 95% activation threshold.

While it is not entirely up to us to decide on this aspect of the specification, we believe that this is what the specification could look like with a specific mitigation.

A change to the specification which adds features such as a malleability fix on the canonical block or committed bloom filter SPV validation of both canonical blockchain (main-chain) and extension block may conflict (but incidentally fulfill) this pull request and we may improve the extension block specification as a result of that design conflict. Doing so would result in removing and superseding this pull request as those features are more important.

We had previously discussed with various miners, at a meeting that we are interested in committed bloom filters and they sounded interested in the idea of decentralized proofs as a better SPV mode. Part of the SPV mode may require an additional specific commitment to the hash of a compact mapping of all input TXOs and outputs of transaction position to avoid full-block download in the event of a hit as an optional speed-privacy tradeoff (but required for block creation) for users doing partial observation of the blockchain.

Note that we do not have any personal opinions on this pull request's particular aspect of implementation and it is up to Developers, Miners, Industry, and Users to support whether this is a good idea. Ultimately, activation of the end result of this specification is an indication of miner approval.